Thanks! Would you please add a short explanation to either the pull request description or commit message outlining why the specialization logic + specialized instructions are thread-safe? I think what's here is correct, but it would be helpful for someone unfamiliar with this code, or if it turns out that our assumptions are invalid.

In this case, I think something like the following would be fine:

• The specialization logic determines the appropriate specialization using only the operand's type, which is safe to read non-atomically (changing it requires stopping the world). We are guaranteed that the type will not change in between when it is checked and when we specialize the bytecode because the types involved are immutable (you cannot assign to __class__ for exact instances of dict, set, or frozenset). The bytecode is mutated atomically using helpers.
• The specialized instructions rely on the operand type not changing in between the DEOPT_IF checks and the calls to the appropriate type-specific helpers (e.g. _PySet_Contains). This is a correctness requirement in the default builds and there are no changes to the opcodes in the free-threaded builds that would invalidate this.

In future, can you please leave sufficient time to review PRs before merging.
Less than 24 hours is not enough. This PR was opened 5pm and merged at 4am UK time.